1. Field of the Invention
The present invention relates generally to the field of computer-controlled process equipment controllers, as well as to the field of control systems. More particularly, the present invention relates to an apparatus and method (i.e., an applications-oriented computer language structure and translator therefor, such as an interpreter or compiler) for developing, describing, and implementing process control of a single process device which participates in batch or continuous industrial process control. The local equipment controller and program for operating the same is generally used in a stand alone configuration wherein the controller directly controls a single vessel processing unit. The method of operating the local equipment controller accommodates the writing of programs in terms of self-documenting statements of control objectives or intentions.
2. Discussion of the Related Art
The present invention has broad application in a wide range of computer-driven control applications and analogous environments. Its virtues and operation will best be understood if it is described in the context of a specific type of control system, rather than in the abstract. For convenience, the context for explanatory purposes will be the field of industrial process control; it should be appreciated, however, that this is simply an exemplary context and is not limiting of the invention.
Industrial process control, as that term is used herein, refers to the control of manufacturing processes in industries wherein a product is, in at least some significant stage of production, a homogeneous fluid capable of being flowed in pipes or a stream of particles capable of being moved by a conveyor belt. The product can be operated upon by simple actuators such as valves, baffles and deflectors and its state can be determined (or at least estimated) by simple probing and sampling sensors. Typical industries included within this framework are those which manufacture petroleum products, chemicals, power, paper, films, metals, textiles, plastics, foods, drugs, cement, and, increasingly, semiconductors.
Industrial processing systems, such as systems for preparing chemical compounds and for controlling other complex operations, frequently implement lengthy and highly detailed procedures. These procedures may involve hundreds, or even thousands, of steps in which various process parameters are monitored and selected process variables are controlled in predefined functional relationships which depend on the monitored parameters. The process variables may be changed continuously or at discrete time intervals. Frequently, the control of such steps involves monitoring one or more measurements and initiating an action or setting a parameter (for example, process variables such as a temperature, pressure, composition, rate of change, amount of change, or the like) in response to the value or condition of the monitored measurement. Additionally, such procedures determine and control when individual processing steps are initiated as well as when they are terminated. Many of these steps typically must be performed in an established temporal relationship relative to one or more other steps. That is, step "x" is begun only after step "y" has been completed, or some predefined interval before or after step "y"; or steps "x" and "y" are carried out concurrently.
There are many ways in which industrial process control systems can be categorized or classified. One of the most basic categorizations groups systems into so-called "batch control" systems (or processes) and so-called "continuous control" systems. In continuous processes in large industrial processing systems, production material is flowed through a series of processing units in such a way that each unit performs a logically independent production step. Control of a continuous process constitutes a continuous computation of the necessary process variables. In batch processing, by contrast, the production material is placed in a vessel (the processing unit) with various pieces of support equipment. That equipment may perform multiple production steps, such as heating, cooling, and pressurizing the vessel. A batch process may carry out all production by itself or it may be arranged in a production line with other batch processes or with continuous units. Batch processing units and continuous processing units themselves may be termed single vessel processing units. Within this specification, the term single vessel processing unit refers to a single processing station, which may be free standing, for accomplishing a particular predetermined processing task or series of tasks. The single vessel processing unit may receive material input from a previous single vessel processing unit and may send its output onto another single vessel processing unit. Large process control systems may be built up from a number of single vessel processing units. An example of a single vessel processing unit might be a retort or a dyebeck.
In some situations, an entire processing complex may occupy more than one square mile. With such a large facility, organization has a significant effect on efficiency. A processing complex typically may be organized into a hierarchy of (from bottom to top) units, processes, and plants. At the lowest levels, the elements may be integrated in an appropriate manner governed by the requirement of meeting the detailed stoichiometric requirements involved in producing a given product. At higher levels, processing may be more flexibly arranged and rearranged to respond to the needs of the business (e.g., to take advantage of the processing units which happen to be available at the time there is a desire to manufacture a given product). The present invention, which is explained below, addresses the lower levels, where there is a desire for a highly integrated automation of control processing; it is well-suited to batch control and continuous control systems which use single vessel processing units. The scheduling and rearrangement of the higher level processing resources is the role of process management, not process control, and is therefore outside the scope of this invention.
In batch processing, the sequencing of the production procedure is divided hierarchically into various levels of operation. The divisions are made generally along the lines of stages of production, operator intervention and monitoring. This facilitates the use of a plant for producing a variety of products. The physical plant resources may be shared so that these products may be produced at different times while using some or all of the same production equipment, either by rearranging the processing or by using the same procedure but varying parameters to yield a different grade of product.
Control automation in this environment must provide a method for imposing control procedures in a relatively simple form.
It is also highly desirable that the control automation process automate the record-keeping associated with the production of each lot, based on the control parameterization and sources of raw materials used therefor; this is important since there is often a need or desire, at some later time, to be able to identify the source of particular characteristics in a product. Further, the record keeping system should have the capability of displaying the recorded data in a variety of different formats, such as bar graphs and line graphs so that trends in process variables or product characteristics can be identified and corrected, if necessary.
Further, a given industrial process may have to be adjusted or changed from time to time--for example, to accommodate a substitution of raw materials or to make an improvement to the product. It is therefore important that the users of a computer-controlled single vessel processing unit be able to identify the portions (and the specific instructions) of the control program which require revision. In the past, these requirements have given rise to a frequently-unfulfilled need for extensive documenting of such programs, parameters, and materials. This level of documentation is only achieved at considerable expense. And undocumented changes could be difficult to detect and analyze.
Various computer languages have been used in the past for developing and implementing process control procedures for both large complex processing systems and single vessel type processing units. Until recently, these languages have included only general purpose computer languages such as FORTRAN, BASIC, PASCAL, C, and other high-level textually-oriented programming languages, as well as specially adapted variants of such languages. Other special purpose languages used for process control applications have included table-based representations of graphic features such as block diagrams and ladder diagrams, either by themselves or in conjunction with textual language features. Only the information contained in the internal table-based representation of the graphic feature has command significance. Moreover, most such prior languages share certain characteristics. For example, they typically require the user to follow a rigid control format using a general purpose instruction set. Further, they provide at best an awkward connection between control functions and the processing objectives which motivate them. These drawbacks are often the result of trying to employ a highly generalized and highly structured language which is implementation oriented instead of being intention oriented. That is, the instruction sets of those prior application or general purpose languages typically emphasize the implementation of an operation as a series of computational instructions, whereas the control system designer is concerned with what he is seeking to accomplish (i.e., his intentions). Consequently, the control system designer, though he is generally not interested in the details of how the machine implements each control operation, is forced to become a computer programmer. Many of the errors introduced in system control programs are believed to be the result of the constant need for mental translation which this regime imposes on the designer.
To make general purpose computer languages more useful in process control, attempts have been made to develop programming strategies to minimize the translation effort. The most obvious of these strategies is the use of subroutines. Subroutines, however, are of only limited benefit. They help when the subroutine requires only a few arguments which act only once each time the subroutine is called. When there are many arguments which must be passed between the main program and the subroutine, though, the subroutine call becomes confusing and the order and meaning of its arguments becomes difficult to remember. Further, it can be an onerous task to link up every argument; and the format is made even more awkward when any of the arguments is optional.
Ambiguity is also a problem in most general purpose programming languages. For example, the expression I=1 could represent a direct calculation, a flag setting, a loop initialization, or some other operation. By contrast, application functions are not likely to be this general.
Another result of the conflict between the application orientation of the control system designer and the implementation orientation of existing application or general purpose programming languages is that control programs written in such languages require an extensive documentation effort, if they are to be intelligible to future users and are to be capable of being modified from time to time. The documentation activity typically is two-fold. First, the source code for the program must be supported with extensive textual comments. Second, a written manual or the like must be prepared to explain the logical organization and features of the program, nomenclature of variables and labels, and other appropriate information. Consequently, each time the program is modified, the comments in the source code must be revised and the manual must be updated. With a program which is being used and modified by a number of people, the support effort needed to maintain up to date documentation is substantial.
A solution to the above described problems was disclosed in U.S. Pat. No. 4,736,320. In that patent, there was described a novel language structure and translator; that is, a new method of operating and programming a computer system thus controlled. The statements employed in this language structure are action-oriented and are specifically adapted for use in constructing process control programs. From these control-oriented statements, appropriate program code may be generated for operation of a computer to implement the desired control functions.
In its most complete implementation, this language structure exhibits the following characteristics: (1) it organizes the control system into logically distinct application subsystems according to processing and control activities; (2) it provides distinct representations for logically different control activities; (3) it orders the display of configured data to make it predictable and easy to read and understand; (4) it represents and displays the program structure graphically, in a way which guides the eye to and through critical relationships; (5) it employs command statements which define precise application function roles, to reduce ambiguity in the underlying intent and in the relationship between the functional elements of a control program; and (6) it uses logical and/or standard application functions and practices to account for implied configuration activities.
Graphical symbols, or icons, are employed to draw the eye to critical features in the control program and to lead the eye through critical interrelationships among the several commands of a complicated control system. At the same time, the translator treats these icons as statements (i.e., commands) which define the relationships among other associated program statements (which are usually textual commands). While prior languages designed for development of documentation have used somewhat similar graphical symbol systems to make the documentation more readable, those graphical symbols have been only passive in nature and have not also served as command statements. Thus, the language structure described in the '320 patent uses as commands a mixture of textual statements and graphic symbols.
Although the approach of the '320 patent represents an improvement over the prior art, for simple applications, the high degree of flexibility and generalization in that language occasionally makes programming tasks more complicated than is necessary when controlling a single vessel processing unit, such as a retort or dyebeck.
In many single vessel process control applications, wherein the control and production system is relatively simple, and also in applications in which the operation of a simple control and production system is largely separated from other units under the control of a single human operator, the number of parameters and variables that need to be controlled is relatively small, and therefore a subset or simplified instruction set of the computer language described in the '320 patent would suffice. Although the subset language may have less flexibility in some applications, it can be implemented more simply, resulting in greater overall efficiency by simplifying the required processing overhead.
Therefore, an object of the present invention is to provide a local equipment controller and method for operating the same, which method includes a subset or simplified instruction set of the computer language described in the '320 patent.
Another object of the present invention is to provide a computer language structure and local equipment controller using the same wherein the language structure allows a control system designer to program in terms of the control functions he desires to implement, rather than in terms of the computer's internal details.
Another object of the present invention is to provide a computer language structure for use in developing programs to control local equipment controllers, such that the control programs are largely self-documenting.
Another object of the present invention is to provide a computer language structure in which the temporal relationships between controlled processes are readily apparent to a reader of a program listing.
Another object of the present invention is to provide a data structure for a programming environment in which supporting details for carrying out control operations are segregated from expressions of control intentions, so as to enhance representation of the control intentions.
Another object of the present invention is to provide a data structure that provides for reduced processing overhead during execution, and provides for certainty and simplicity of execution.
Another object of the present invention is to provide a local equipment controller having a predefined set of control solutions for controlling a variety of processes supplied therewith.
Another object of the present invention is to provide a programming format that is fixed so that control intentions and understanding of program control is enhanced.
Another object of the present invention is to provide a user interface in a local equipment controller which user interface provides an operator user interface and a programming user interface wherein the user interface makes use of graphic features which have command significance.